Skip to content

Move portable container machine maps to JSON config files (#6188) - #7512

Open
Akshat005Chaudhary wants to merge 1 commit into
adoptium:masterfrom
Akshat005Chaudhary:akshat_branch_4
Open

Move portable container machine maps to JSON config files (#6188)#7512
Akshat005Chaudhary wants to merge 1 commit into
adoptium:masterfrom
Akshat005Chaudhary:akshat_branch_4

Conversation

@Akshat005Chaudhary

Copy link
Copy Markdown
Contributor

Summary

Moves the hardcoded imageUploadMap and imagePullMap Groovy maps out of openjdk_tests
and into external JSON config files, completing the second phase of the Portable Container
Testing setup described in #6188.
Closes #6188
Related: automation/issues/294

Background

PR #6195 ("Set up pipeline for criu and portable SCC") added inline Groovy maps for both
CRIU and portable SCC directly into openjdk_tests. During review, it was acknowledged
that this mapping would eventually move to a separate config file to make the pipeline
extensible without requiring code changes.
This PR implements that config-folder approach.

Changes

New: buildenv/jenkins/config/portable-container/

config/portable-container/
├── README.md
├── criu/
│   ├── imageUploadMap.json   # machine combinations for CRIU image upload
│   └── imagePullMap.json     # machine combinations for CRIU image pull/restore
└── scc/
    ├── imageUploadMap.json   # machine combinations for SCC image upload
    └── imagePullMap.json     # machine combinations for SCC image pull/restore

Each imageUploadMap.json carries:

  • commonLabelBase — base Jenkins node label for the feature
  • buildListBUILD_LIST value for child jobs
  • targetTARGET value for upload child jobs
  • excludeTargetOnPlatform — platform-specific test exclusions (e.g. CRIU ppc64le backlog/1099)
  • platforms — map of platform → list of label suffixes

Each imagePullMap.json carries:

  • commonLabelBase
  • platforms

Modified: buildenv/jenkins/openjdk_tests

  • Replaces all hardcoded Groovy imageUploadMap/imagePullMap blocks with a
    node { checkout scm; readJSON(...) } config-loading block (same pattern as
    aqaTestPipeline.groovy).
  • Uses findFiles(glob: ".../portable-container/*/imageUploadMap.json") for
    auto-discovery — the pipeline detects supported features from the directory
    structure at runtime.
  • All orchestration logic (generateJobViaAutoGen, parallel, build job:,
    changeParam) is unchanged.
  • CRIU JDK26+ skip and ppc64le target exclusion are fully preserved.

Net result: −104 / +63 lines in openjdk_tests.

How to Add a New Feature (after this PR)

  1. Implement tests in aqa-tests/external/<feature>/
  2. Create buildenv/jenkins/config/portable-container/<feature>/imageUploadMap.json
  3. Create buildenv/jenkins/config/portable-container/<feature>/imagePullMap.json

No changes to openjdk_tests required.

Testing

  • All 4 JSON files validated as syntactically correct JSON.
  • Logic simulation confirms the Groovy maps constructed from JSON are
    identical to the previous hardcoded maps for all platforms (CRIU: 15 upload
    • 14 pull entries; SCC: 4 upload + 4 pull entries).
  • CRIU target string, ppc64le exclusion substring, and resulting target-after-exclusion
    all verified to match the original values exactly.

)

Replace hardcoded imageUploadMap and imagePullMap Groovy maps in
openjdk_tests with JSON config files under a new config folder:

  buildenv/jenkins/config/portable-container/
  ├── README.md
  ├── criu/
  │   ├── imageUploadMap.json
  │   └── imagePullMap.json
  └── scc/
      ├── imageUploadMap.json
      └── imagePullMap.json

The pipeline now auto-discovers feature types via findFiles(), so adding
support for a new feature only requires adding the corresponding JSON
files — no changes to openjdk_tests are needed.

Follows the same node/checkout scm/readJSON pattern used in
aqaTestPipeline.groovy.

Related: automation/issues/294

@karianna karianna left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM not sure if Dockerfiles for 26 now exist though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Portable Container Testing

2 participants